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Differentiated charging in packet data networks 
Field of the invention 

5 This invention pertains to the area of charging in mobile packet data networks. More par- 
ticular, the invention relates to real time based differentiated charging of pre-paid ser- 
vices in General Packet Radio Services (GPRS) networks. 

Background of the invention 

10 

As in most businesses it is important for telecom operators to price differentiate services 
to their users in order to maximise profits. Parameters such as duration of telephone 
conversation, user class of service, distance, time of day of conversation and user ser- 
vice classes have been used in pricing models allowing for high a capacity utilisation. 
15 Recently, the advent of GPRS has made it possible to charge customers, according to 
the amount of data, which is transmitted to and from the mobile terminal in question, 
such that the user is not charged for downtime and interruptions. 

Mobile pre-paid subscriptions, i.e. a subscription type involving a fixed credit limit often 
20 associated with the acquisition of a "pre-paid" SIM card, have recently shown strong 
growth. As opposed to traditional subscribers, which can be billed after the service is 
delivered, operators need the ability to terminate services to pre-paid customers in case 
the credit limit of a given user is reached. Since the service delivered to the user may 
involve many operators, possibly virtual operators, an exact and prompt measurement of 
25 service utilisation is therefore needed. Pre-paid services, has therefore necessitated an 
ability to charge in "real time". 

It is believed that new services such as MMS will be one important driver for the change 
to 3G networks. A consistent pricing model of such services is believed to be important 
30 for users to adopt them. Advantageously, the user should expect a fixed "low" price level 
for transmitting a MMS, such that the service is perceived as being equivalent to other 
competing services, such as sending a post card. It is noted that a picture of a given 
resolution may be of varying data size depending on the coding principle and the motive 
captured. 

35 

According to the 3'rd generation partnership project (3GPP) technical specification, 3G 
TS 23.060 a common packet domain Core Network is used for both GSM and UMTS. 

1 
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Such a system has been shown in fig. 1 . A similar system has been shown in 
WO99/05828. 

The above Core Network provides packet-switched (PS) services and is designed to 
5 support several quality of service levels in order to allow efficient transfer of non real- 
time traffic (e.g., intermittent and bursty data transfers, occasional transmission of large 
volumes of data) and real-time traffic (e.g., voice, video). One class of quality of service 
pertains to a low throughput and a low delay; another class pertains to higher throughput 
and longer delay and a further class pertains to relatively long delays and high through- 
10 put. 

Applications based on standard data protocols and SMS are supported, and interworking 
is defined with IP networks. Charging is rendered flexible and allows Internet Service 
Providers to bill according to the amount of data transferred, the QoS supported, and the 
15 duration of the connection. 

Each PLMN has two access points, the radio interface (labelled Urn in GSM and Uu in 
UMTS) used for mobile access and the R reference point used for origination or recep- 
tion of messages. 

20 

An interface differs from a reference point in that an interface is defined where specific 
information is exchanged and needs to be fully recognised. There is an inter PLMN inter- 
face called Gp that connects two independent packet domain networks for message ex- 
change. There is also a PLMN to fixed network (typically a packet data network) refer- 
25 ence point called Gi. 

There may be more than a single network interface to several different packet data (or 
other) networks. These networks may both differ in ownership as well as in communica- 
tions protocol (e.g., TCP/IP etc.). The network operator should define and negotiate in- 
30 terconnect with each external (PDN or other) network. 

Network interworking is required whenever a packet domain PLMN and any other net- 
work are involved in the execution of a service request. With reference to figure 1, inter- 
working takes place through the Gi reference point and the Gp interface. 
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The internal mechanism for conveying the PDP (Packet Data Protocol) PDU (Packet 
Data Unit) through the PLMN is managed by the PLMN network operator and is not ap- 
parent to the data user. The use of the packet domain data service may have an impact 
on and increase the transfer time normally found for a message when communicated 
5 through a fixed packet data network. 

The packet domain supports interworking with networks based on the Internet protocol 
(IP). The packet domain may provide compression of the TCP/IP header when an IP 
datagram is used within the context of a TCP connection. 

10 

The packet domain PLMN service is an IP domain, and mobile terminals offered service 
by a service provider may be globally addressable through the network operator's ad- 
dressing scheme. 

15 A GPRS Support Node (GSN) contains functionality required to support GPRS function- 
ality for GSM and/or UMTS. In one PLMN, there may be more than one GSN. 

The Gateway GPRS Support Node (GGSN) is the node that is accessed by the packet 
data network due to evaluation of the PDP address. It contains routing information for 
20 PS-attached users. The routing information is used to tunnel N-PDUs to the MS's current 
point of attachment, i.e., the Serving GPRS Support Node. The GGSN may request lo- 
cation information from the HLR via the optional Gc interface. The GGSN is the first 
point of PDN interconnection with a GSM PLMN supporting GPRS (i.e., the Gi reference 
point is supported by the GGSN). GGSN functionality is common for GSM and UMTS. 

25 

The Serving GPRS Support Node (SGSN) is the node that is serving the MS. The SGSN 
supports GPRS for GSM (i.e., the Gb interface is supported by the SGSN) and/or UMTS 
(i.e., the lu interface is supported by the SGSN). 

30 In order to access the PS services, an MS shall first make its presence known to the 
network by performing a GPRS Attach. This makes the MS available for SMS over PS, 
paging via the SGSN, and notification of incoming PS data. According to the Attach, the 
IMSI (International Mobile Subscription Identity) of the mobile station (MS) is mapped to 
one or more packet data protocol addresses (PDP). 

35 
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At PS Attach, the SGSN establishes a mobility management context containing informa- 
tion pertaining to e.g., mobility and security for the MS. 

In order to send and receive PS data, the MS shall activate the Packet Data Protocol 
5 context that it wants to use. This operation makes the MS known in the corresponding 
GGSN, and interworking with external data networks can commence. 

At PDP Context Activation, the SGSN establishes a PDP context, to be used for routing 
purposes, with the GGSN that the subscriber will be using. 

10 

According to the PDP context activation, a network bearer (IP) communication between 
the mobile station and for instance the Internet service provider (ISP) may be estab- 
lished. Moreover, a given class of Quality of Service is assigned for the communication 
to be performed. 

15 

The SGSN and GGSN functionalities may be combined in the same physical node, or 
they may reside in different physical nodes. SGSN and GGSN contain IP or other (op- 
erator's selection, e.g., ATM-SVC) routing functionality, and they may be interconnected 
with IP routers. In UMTS, the SGSN and RNC may be interconnected with one or more 
20 IP routers. When the SGSN and the GGSN are in different PLMNs, they are intercon- 
nected via the Gp interface. The Gp interface provides the functionality of the Gn inter- 
face, plus security functionality required for inter-PLMN communication. The security 
functionality is based on mutual agreements between operators. 

25 The SGSN may send location information to the MSC/VLR via the optional Gs interface. 
The SGSN may receive paging requests from the MSC/VLR via the Gs interface. 

The SMS-GMSCs and SMS-IWMSCs support SMS transmission via the SGSN. Option- 
ally, the MSC/VLR can be enhanced for more-efficient co-ordination of packet-switched 
30 and circuit-switched services and functionality: e.g., combined GPRS and non-GPRS 
location updates. 

User data is transferred transparently between the MS and the external data networks 
with a method known as encapsulation and tunnelling: data packets are equipped with 
35 PS-specific protocol information and transferred between the MS and the GGSN. This 
transparent transfer method lessens the requirement for the PLMN to interpret external 

4 
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data protocols, and it enables easy introduction ot additional interworking protocols in 
the future. 

An Application Server (AS) is connected to the Packet Data Network (PDN) for providing 
5 information. An Internet Service Provider (ISP), the PLMN, or an independent company 
may own the application server. The application server may offer MMS. 

The packet domain logical architecture, as defined in 3GPP TS 23.060, defines the pro- 
tocols involved in the various nodes. Fig. 2 shows the user plane protocol stacks, as de- 
10 fined in the 3GPP TS 23.060 for GSM. Fig. 3 shows the user plane protocol stacks, as 
defined in the 3GPP TS 23.060 for UMTS. 

In both cases shown in fig. 2 and 3, the GTP-U protocol conveys both uplink and 
downlink payload between SGSN and GGSN nodes, the Gn (or Gp in a roaming situa- 
15 tion) interface. Fig. 2 and 3 shall not be explained further as their content is well known 
in the art. 

Charging 

20 In a mobile packet data network, real-time pre-paid charging may rely on the use of 
CAMEL as standardized in 3GPP TS 22.078, 23.078 and 29.078. 

In fig. 4, the charging performed in known GPRS networks have been further illustrated. 
As appears from the figure, the SGSN may belong to a first operator 1 - which may be 
25 denoted as a visitor public land mobile network (VPLMN) and the GGSN may belong to 
a second operator 2 - which may be denoted as a home public land mobile network 
(HPLMN). This node may for instance belong to operator 2. 

Respective Charging Gateway Functionality (CGF) in individual nodes collects charging 
30 records from SGSNs and GGSNs. The HLR (Home Location Register) contains GSM 
and UMTS subscriber information. The HLR stores the IMSI (International Mobile Sub- 
scription Identity) and maps the IMSI to one or more packet data protocol addresses 
(PDP) and maps each PDP address to one GGSN. 
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The SGSN provides S-CDR (SGSN Charging Data Kecord) charging reports relating to 
transmitted traffic according to a PDP context to a CGF. The S-CDR reporting is not per- 
formed on a real time basis, and hence inapt for real time charging. 

5 The GGSN also performs collection of charging information on the same traffic relating 
to a given PDP context, travelling through the GGSN by providing G-CDR (GGSN 
Charging Data Record) reports. The amount of traffic may be slightly different from the 
measurements performed in the SGSN. The G-CDR reporting is not performed on a real 
time basis. 

10 

As indicated in fig. 4, a CAMEL SCP (Service Control Point) node collects charging re- 
ports over the Ge interface using the Camel Application Part (CAP) protocol. The 
CAMEL standard caters for reporting transferred payload volume as a single measure- 
ment, uplink and downlink together. The CAMEL interaction (Ge interface) reports the 
15 appropriate PDP context resource utilization to a pre-paid system (CAMEL GSM-SCF). 
The SGSN however lacks the ability to discriminate different kinds of payload flowing 
through the PDP context. 

The prime basis for charging in a mobile packet data network (GPRS in GSM and UMTS 
20 networks) is anticipated - and indicated by operators - to be the amount of transmitted 
payload in a PDP context. According to 3GPP TS 32.200, it is the "Usage of the radio 
interface " that is to be measured, i.e. measurements are performed on the SNDCP 
layer (Gb interface) for GSM and on the GTP-U layer (lu interface) for UMTS. 

25 Services may be charged for separately, but still provided through the same PDP con- 
text. The payload required to provide the service should not (normally) be accounted for 
with respect to amount of payload to charge. 

A known Packet Inspection and Service Classification (PISC) system interacting with a 
30 GGSN node has been provided and sold by Ericsson under the name "Flexible Bearer 
Charging (FBC) system". Currently, such systems are dealt with under the designation 
Traffic Plane Function (TPF) in 3GPP TR 23.825. The PICS system performs packet in- 
spections for given PDP contexts and assesses the given class of service used for the 
given PDP context. Based on the inspection, the FBC functionality provides reports of 
35 the volume of traffic for the given class of services provided. The FBC may provide vol- 
ume and class for each PDP packet sent or received in a given PDP context. 

6 
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The GGSN lacks a standardized real time charging interface towards a pre-paid system. 
The GGSN moreover lacks a control mechanism to be used for shutting down a PDP 
context, when the user account is empty. 

5 

Fig. 5, 6 and 7 show various known GTP header formats as defined in 3GPP TS 29.060. 
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Summary of the invention 

it is a first object of the invention to set forth a method for a more efficient monitoring of 
charging in a mobile packet data network. 

5 

This object had been accomplished by the subject matter set forth in claim 1 . 

It is a second object of the invention to set forth a packet data unit enabling a more effi- 
cient monitoring of charging in a mobile packet data network. 

10 

This object had been accomplished by the subject matter set forth in claim 6. 

It is a third object of the invention to set forth a gateway node providing a more efficient 
monitoring of charging in a mobile packet data network. 

15 

This object had been accomplished by the subject matter set forth in claim 14 and 15. 

It is a fourth object of the invention to set forth a serving node providing a more efficient 
monitoring of charging in a mobile packet data network. 

20 

This object had been accomplished by the subject matter set forth in claim 16. 

It is a fifth object to set forth a gateway node that provides for charging in a mobile 
packet data network, in cases where service classification cannot be performed momen- 
25 tarily. 

The gateway nodes according to claims 20 and 21, respectively, have achieved this ob- 
ject. 

30 According to the invention true real-time control over resource usage is achieved in both 
HPLMN and VPLMN. Both HPLMN and VPLMN operator's non-chargeable network traf- 
fic is reduced compared to near real-time charging solutions. 

Further objects and advantages will appear from the following detailed description of the 
35 invention. 

8 
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Brief description of the drawings 



Fig. 1 shows an overview of the common domain core network according to the 

5 known 3GPP specification, 

fig. 2 and 3 shows known user plane protocol stacks for GSM and UMTS, respec- 
tively, 

10 fig. 4 discloses a known CAMEL reporting procedure, 

fig. 5 shows the prior art GTP PDU header format, 

fig. 6 shows the prior art extension header format for the GTP PDU format, 

15 

fig. 7 shows the status for respective bit settings for the next extension header 

type of fig. 5, 

fig. 8 is an overall illustration of the preferred embodiments according to the 

20 invention relating to a GPRS network comprising at least a serving GPRS 

support node (SGSN) and a gateway GPRS support node (GGSN), 



fig. I a + b illustrates a charging and IP packet flow including packet construction for 
a first embodiment of the invention, 

25 

fig II a + b illustrates a charging and IP packet flow including packet reception and 
CAMEL reporting for a first embodiment of the invention, 

fig. Ill a + b illustrates a charging and IP packet flow including packet construction for 
30 a second embodiment of the invention, 



fig. IV a + b illustrates a charging and IP packet flow including packet construction for 
a third embodiment of the invention, 



35 fig. 9 



discloses a first embodiment of an extension header type according to the 
invention, and 

9 
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fig. 10 discloses a second embodiment of an extension header type according to 

the invention. 

5 

Description of a first preferred embodiment of the invention 

In figure 8, an exemplary illustration of a preferred embodiment has been shown relating 
10 to a GPRS network comprising at least a serving GPRS support node (SGSN) and a 
gateway GPRS support node. According to the invention, charging information (CI) re- 
lating to a particular PDP context for a given mobile station is gathered in the GGSN / 
PISC and is transmitted in a GTP header extension to the SGSN. The charging informa- 
tion is signalled at reception at the SGSN to a charging node (SCP) associated with the 
15 SGSN. 

According to the invention, after a PDP context is activated for a given user, the GGSN 
resolves the kind of PDP (e.g. IPv4, Ipv6), and resolves the class of service of the PDP 
PDUs at the Gi interface. Examples of such service classes are MMS traffic, stock mar- 
20 ket information, positional information etc. 

The present invention makes use of a Packet Inspection and Service Classification 
(PISC), such as the Ericsson FBC (Flexible Bearer Charging) system, for analyzing GTP 
traffic according to a given PDP context and hence according to a given user. The gate- 
25 way node, GGSN, is communicating with the packet inspection and service classification 
system, PISC, to which IP packets may be communicated for identification of a given 
service class out of a number of predetermined service classes. 

The analysis is performed on a packet-to-packet basis, and provides associated values 
30 of PDP context, estimated class of service value and associated payload volume value. 
The PISC data, in the following denoted class of service data and volume, may be 
evaluated, accumulated and transformed into reports. Since packet inspection is a diffi- 
cult task, it may not always be possible to classify the payload packet transmitted; hence 
at least a non-successfully evaluated class of service value may be assigned to the 
35 class of service data. Depending on the extent the information can be classified, reports 
may be established which allows for a tolerance assessment or worst-case assessment. 

10 
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For instance, it could be an object not to charge for more than provided, should any in- 
accuracy in the system be detected. 

It should be noted that the PISC system could be an integrated part of the GGSN and 
the functioning could be based on software. 

The above PISC system interacts with the GGSN and according to the invention the 
GGSN inserts class of service values in the stream of data transmitted to the SGSN. 
From here, the class of service data together with charging information obtained in the 
SGSN node is transmitted using normal CAMEL reporting procedures to the CAMEL 
SCP. This route for the charging information (CI) pertaining to a first embodiment of the 
invention has been shown in fig. 8, which will be further dealt with under figs, la and lb. 

There is no restriction as to what and how many classes of services may exist, but the 
encoding scheme must be the same at the GGSN and the CAMEL gsmSCF / SCP. 

According to the invention, at least one special extension header is added to a GTP-U 
header for a given GTP packet to be transported, on at least the Gn/Gp interface be- 
tween the GGSN and the SGSN. In this special extension header data related to at least 
a particular service class for a given PDP context is stored. It should be noted that the 
class of service data carried in the special extension header might be associated with 
the subsequent payload carried under the extension header. However, the service class 
data of the special header extension is not necessarily associated with the payload of 
the GTP packet, which is carried under the given extension header. 

The GTP header, as shown in figure 5, is flexible since the extension format according to 
the current GTP standard, as shown in figure 6, can be added to a default header. 

According to a preferred embodiment of the invention, the list of GTP header extension 
types, defined in 3GPP TS 29.060, is provided with a new GTP-U header extension 
type, which indicates that the extension header comprises class of service information. 
For instance the marker value 01 10 0000 can be used as "next extension header type' 
cf. fig. 5, for indicating that a GTP extension header follows including service class in- 
formation. 
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The extension header type may indicate that the receiver endpoint is not obliged to in- 
terpret the information and that it shall be passed on to the SGSN that transmits the 
GTP-U content towards the radio network. Setting Bits 8 and 7 of the marker value to 
adopt the values 0 and 0 accomplishes this task, cf. fig. 7. 

5 

The above measures will make information available at the CAMEL SCP node, so that 
different ratings can be applied on a per payload class of service basis. 

In fig. 9, a first embodiment of an extension header type is shown. The first octet relates 
10 to the size of the extension header that in this case always has the size of 4 octets indi- 
cated by the length field value of 1. 

The extension moreover comprises a main service class field and a subclass field. The 
provision or the use of the subclass field is optional. As required for extension headers, 
the last octet comprises a field for indication whether a further extension header is added 
15 in the GTP packet. 

In fig. 10, a second embodiment of an extension header according to the invention is 
shown. This extension header is larger than the first one and comprises additionally a 
volume count relating to how big the payload volume is for a given service class. 

20 

According to the preferred embodiment The Payload class of service information in- 
cludes a "Class of service only" if the complete PDP payload in a GTP-U PDU has the 
same class of service or a "Class of service and volume" for other implementations, such 
as if the class of service information applies to part of the PDP payload in a GTP-U PDU 
25 or the class of service information applies (in part or full) to payload conveyed in another 
GTP-U PDU or if the class of service information applies to the PDP payload in more 
than one GTP-U PDU. 

The "class of service only" GTP-U header extension format, shown in fig. 9, is applicable 
30 if the entire PDP PDU payload in the GTP-U packet falls in the same class of service. 

One "class of service and volume" GTP-U header extension, shown in fig. 10, is inserted 
for each class of service, for which volume information shall be conveyed to the SGSN. 
This format is needed for conveying class of service information on uplink payload to the 
35 SGSN. 

12 
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The Main class of service and Subclass of service encoding can be arranged as desired. 
It is envisaged that MMS traffic could constitute a first class of service, positional ser- 
vices constitute another class of service and all other traffic could constitute a third class 
of service. The subclass could be used for an additional level of resolution. 

5 

The SGSN maintains one counter for the volume of each service class, and subclass if 
provided, for a certain PDP context. 

First embodiment - fig. I a & b 

10 

Fig. la+b illustrates the packet construction for a first embodiment of the invention. 

In step 1 the IP packet arrives at the Gi interface in the GGSN. The IP packet payload is 
extracted. Subsequently the IP packet is identified as part of a PDP context and the IP 

15 packet is stored in GTP-U PDU. The Packet Inspection and Service Classification 

(PISC) analyses the content of the payload and identifies a service class value for the IP 
packet in step 3. Thereafter, a GTP-U extension header containing the identified service 
class value is prepared in the GGSN, confer step 4. This special extension header is in- 
serted, see step 5, as part of the GTP-U PDU for which the service class value was as- 

20 signed. Finally, in step 6, the GGSN sends the GTP-U PDU downstream towards the 
SGSN. 

Fig. II a & b 

25 In fig. II a & b the subsequent actions taken in the GGSN for the first embodiment is illus- 
trated. The GTP-U PDU mentioned above is reaching the SGSN on the Gn interface as 
shown in step 1. In step 2', the service class value is extracted from the extension 
header. The SGSN measures the payload volume of the incoming packet and stores the 
service class value of the payload, step 3\ This volume information is accumulated for 

30 given respective service classes for a given PDP context in the SGSN reporting unit. 

Following normal CAMEL reporting procedures, the SGSN reports CAMEL measure- 
ment, as shown in step 4. More specifically, the Ge interface CAP operation Apply- 
ChargingReportGPRS is augmented with information on classified payload. The class of 
35 service counters are reported to the SCP in a new information element ClassifiedPay- 
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load in the known ApplyChargingGPRS operation to the SCP. This transfer may for in- 
stance be performed over a SS7 network. 

The SCP, which maintains the balance of the subscriber's account, may use the classi- 
5 fied payload information for rating. The information elements specified in the present 
3GPP specification for the ApplyChargingReportGPRS CAP operation are not affected, 
i.e. payload volumes and thresholds are still reported with total amount of payload. In- 
clusion of measurement reports of classified payload is conditionally added to the Ap- 
plyChargingReportGPRS CAP operation in a backward compatible way. 

10 

The SCP must have a list of service classes that affects the rating of payload transfer. 
The SCP may prepare the SGSN to report only those service classes in the ApplyCharg- 
ingGPRS operation: 

15 Reporting classified payload volume does not mandate classifying all payloads. Such 
"not classified" payload can be inferred from the total measured payload, reduced with 
the sum of all classified payload. The non-classified payload may be assigned to a de- 
fault class as opposed to perform volume charging. 

20 The SCP uses the standard CAMEL procedures to shut down services when the ac- 
count is exhausted. 

One advantage of the invention is that the classified payload measurements - that are 
best produced at the GGSN where the GTP tunnel is ended, the PDP type is known and 

25 the PDP payload is observable - are made available to an SCP over the known Ge inter- 
face from the SGSN without requiring any new interfaces. Moreover, the transfer of ser- 
vice class and size information from the GGSN to the SGSN does not require any new 
GTP PDU type, or any other protocol. The transfer according to the invention would con- 
stitute an optional feature and is a backward compatible extension to the GTP-U PDUs 

30 that are handled by existing SGSN / GGSN. Moreover, given the GGSN provides the 
payload service class information for downlink payload in the same GTP-U PDU as the 
actual payload transfer. The classified measurement fulfils the same accuracy require- 
ments as the local measurement of total downlink payload at the SGSN. Also, the trans- 
fer of service class and volume information from the SGSN to the SCP using the Ge in- 

35 terface is a backward compatible extension to existing CAP operations and do not affect 
prior art CAMEL reporting procedures. 
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For the embodiment corresponding to figs, la+b and lla+b downstream packets are re- 
ported as shown. Upstream packets may be provided separately using the known 
CAMEL interface. 

5 

In steps 2 and 3, an alternative path is shown for the case wherein both volume count 
and service class is provided in the extension header. In step 2 both the service class 
and volume count is extracted. Consequently in step 3, the values are a stored as sepa- 
rate information of the PDP context. 

10 

Second embodiment - Fig. Illa+b 

In fig III a + b a second embodiment of a charging and IP packet flow according to the 
15 invention has been shown. 

A first down stream IP packet arrives at the GGSN at the Gi interface, step 1 . 

The first IP packet is identified as part of a PDP context and the packet is stored in a first 
20 GTP-U PDU, step 2. 

By way of example, the first IP packet payload class can not be identified separately, 
step 3. 

25 The PISC saves measurement information of the non-classified IP packet payload, step 
4. 

The GGSN transmits the GTP-U PDU downstream towards the SGSN, step 5. 

30 According to step 5', steps 1-5 may be repeated before continuing. 

In step 6, a second exemplary downstream IP packet arrives at the Gi interface. 

The second IP packet is identified as being part of the same PDP context as the first 
35 non-classified IP packet and the received IP packet is stored in a GTP-U PDU, step 7. 

The second IP packet is identified and classified by the PISC, step 8. 
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The first non-classified IP packet is correlated to the second IP packet, so this service 
class is assigned to both the first and the second IP packets, step 9. The correlation may 
be based on the type of used protocol, source address, port number as well as potential 
5 underlying protocol specific information. 

A GTP-U header is prepared with the service-classified identity and associated volume 
count, whereby the volume count represents the sum of the not yet reported volume 
count of the service class for the PDP Context, step 10. 

10 

The GTP-U header is included as part of a second GTP-U PDU for which the classifica- 
tion was performed, step 1 1 . 

Finally, the GGSN transmits the second GTP-U PDU to the SGSN. 

15 

When the two above GTP-PDUs are received in the SGSN, the PISC data is extracted in 
so far as extension headers are provided in respective GTP-PDUs. This procedure cor- 
responds closely to the one illustrated in fig. I la and b. 

20 An alternative embodiment could also be envisaged that identifies a first service class for 
a first but not a second later IP, packet - in this case, the classification should be stored 
and assigned for the second packet. 

In the second and third embodiment explained above, the PISC performs a partial or in- 
25 complete classification and stores incomplete classifications and associated volume 

counts in memory. The term partial classification should be understood in the sense that 
it is not possible to unambiguously identify the given payload, of a given volume count, 
to a specific service class. This means that the given volume count cannot be reported 
as part of a specific class at that particular moment. Additional information gathered from 
30 succeeding payload packets of the same service are needed for an unambiguous classi- 
fication of the aggregated volume of the payload in question belonging to a given PDP 
context. 

Third embodiment - Fig. IVa+b 

35 
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In fig IV, an example has been shown which relates to a PDP context session in which 
messages are both transmitted upstream (on the up-link) and downstream (the down- 
link). 

5 In step 1 , an upstream GTP-U PDU arrives at the Gn interface of the GGSN. 
A first IP packet is extracted from the GTP-PDU, step 2. 

The first IP packet payload is identified and classified by the PISC if possible, step 3. By 
10 way of example the first IP payload is identified as belonging to a first service class. 

The PISC saves information for the classified first IP packet associated with the given 
PDP context, step 4. A cumulative volume pertaining to a respective service class and 
PDP context is updated in the PISC. 

15 

The GGSN sends the upstream IP packet towards the Gi interface, step 5. 

The steps 1-5 may be repeated before continuing. If more upstream packets arrive and 
no downstream packet arrives, the volume count of classified upstream payload packets 
20 are accumulated until a downstream payload packet for the same PDP Context appears. 

If no more upstream packets or if a downstream packet arrives, the process moves on to 
step 7, whereby a first arriving downstream payload packet will carry the in PISC accu- 
mulated classified volume counts for the same PDP Context. 

25 

If no more upstream packets and no downstream packets arrive, the process moves on 
to step 1 0. 

The procedures of both classification and of accumulation of volume reports from both 
30 fully classified and partial classified payload volume are maintained as long as the PDP 
Context is active. Not yet reported volume counts at PDP Context deactivation are sim- 
ply discarded or is transmitted in an empty GTP-U packet. 

In step 6, the SGSN may await more IP packets belonging to the PDP context and re- 
35 sume the steps 1 - 5 for subsequent packets. When a downstream second IP packet 
arrives belonging to the same PDP context the accumulated classified volume counts 

17 



WO 2005/053224 



PCT/SE2003/001829 



are reported, arranging associated values of service class and volume count in a sepa- 
rate extension header. 

The downstream second IP packet is stored in a GTP-U PDU, step 7. 

5 

The second IP payload is identified and classified by the PISC, step 8. By way of exam- 
ple, the second IP payload is identified as belonging to a second service class. 

In step 9, the second IP packet is identified as part of the same PDP context as the ear- 
10 lier non-reported first IP packet payload measurement. 

A first GTP-U extension header is prepared carrying the service class identity from at 
least one saved measurement of upstream IP packets, step 10. Byway of example, the 
payload is of a first service class type. 

15 

The first GTP-U extension header, step 1 1 , is included as part of the downstream GTP- 
U PDU. 

A second GTP-U extension header is prepared with the identified service class identity 
20 of the downstream second IP packet, step 12. 

The second GTP-U extension header is included as part of the common GTP-U PDU, 
step 13. 

25 The GGSN transmits the common GTP-U PDU, step 14. 

In the above embodiment above, the GTP-PDU carry more than one extension header. 
One extension header is added for each new category being reported. 

30 According to the embodiments set out above, true real-time control over GPRS resource 
usage is achieved. The first embodiment has the advantage of providing a very fast re- 
porting. The second and third embodiments do not provide for as swift a reporting as the 
first embodiment, but provides a higher reliability of the service classification. 

35 Thereby GPRS pre-paid service is accomplished which provides for separate charging 
per service utilisation of payload transport. According to an advantageous aspect of the 
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invention, the service-related payload is deducted from the gross payload, whereby 
charging can be accomplished for both PDP context usage and services. 

As mentioned above, existing protocols and interfaces, such as the known CAMEL re- 
porting mechanisms are used such that the embodiments are backward compatible with 
the current 3GPP standard. 
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Abbreviations 



CAMEL Customised Applications for Mobile network Enhanced Logic 

CDR Charging Data Record 

5 CGSN A node combining SGSN and GGSN functionality 

Ge CAMEL interface between GSM-SCF and SGSN nodes 

GGSN Gateway GPRS Support Node 

Gn Interface between two GSNs within the same PLMN 

Gp Interface between two GSNs in different PLMNs. The Gp interface al- 
io lows support of GPRS network services across areas served by the co- 
operating GPRS PLMNs 

GPRS Packet Services for GSM, UMTS or GERAN systems 

gprsSSF GPRS Service Switching Function 

GSM Global System for Mobile communications 

15 GSM-SCF GSM Service Control Function (in spite of the "GSM", applies to GPRS 

and UMTS as well) 

gsm SCF GSM Service Control Function 

GTP GPRS Tunnelling Protocol 

GTP' GTP variant for transporting CDR information 

20 GTP-U GTP User Plane 

HPLMN Home PLMN 

MMS Multimedia Messaging Service 

MS Mobile Station, the MT and TE together 

MT Mobile Terminal 

25 PDP Packet Data Protocol. 

PDU Protocol Data Unit. 

PLMN Public Land Mobile Network 

SCP synonym for GSM-SCF 

SGSN Serving GPRS Support Node 

30 TE Terminal Equipment 

UMTS Universal Mobile Telecommunications System 

VPLMN Visited PLMN 
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Patent claims 

1. Method of communicating charging information (CI) in a network comprising at 
least a serving node (SGSN) and a gateway node (GGSN) wherein 
charging information (CI) relating to a particular PDP context for a given mobile 
station is gathered in the gateway node and transmitted in a GTP header exten- 
sion to a serving node (SGSN). 

2. Method according to claim 1, wherein the charging information (CI) at reception at 
the serving node (SGSN) is signalled to a charging node (SCP) associated with 
the serving node (SGSN). 

3. Method according to claim 2, wherein the charging information (CI) is at least gath- 
ered by performing packet inspection of the transmitted packet and assigning a 
predefined service class to the packet. 

4. Method according to claim 2, wherein the charging node signalled to is a CAMEL 
SCP node and the charging information is reported by means of the CAP protocol. 

5. Method according to any previous claim, wherein the network is a GPRS network, 
the serving node is Serving GPRS Support Node (SGSN), and the gateway node 
is a Gateway GPRS Support Node (GGSN). 

6. A packet data unit comprising 

a header, at least one extension header and a payload, wherein 
the header comprises a next extension header type indicating that a pre- 
determined service class extension header follows that is reserved for comprising 
service class information pertaining to at least one IP packet payload for a given 
PDP context for a user. 

7. Packet data unit according to claim 6, wherein the service class information at 
least relates to the service class of the payload carried by the packet data unit 
comprising the service class extension header. 

8. Packet data unit according to claim 7, wherein the service class extension header 
moreover comprises a volume count pertaining to the amount of payload being 
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transmitted in the same packet data unit carrying the service class extension 
header and belonging to a given PDP context 



Packet data unit according to claim 6, wherein the service class information relates 
to the service class of the payload of IP packets transmitted in other packet data 
units relating to the same PDP context and wherein the volume count relates to 
the aggregate volume of the given classified payload. 



10. Packet data unit according to claim 9, wherein the payload data relates both to 
data transmitted upstream and downstream for a given mobile user for a given a 
PDP context. 

1 1 . Packet data unit according to claim 9, wherein at least two service class extension 
headers are comprised in the packet data unit, whereby the service class exten- 
sion headers relates to different service classes. 

1 2. Packet data unit according to any of claims 6-11, wherein the packet data unit is 
a GTP-U PDU packet and the payload is a GTP-U PDU payload. 



1 3. The packet data unit according to any of claims 6-11, wherein the extension 
header comprises at least a main service class field and a sub-class field. 
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14. A gateway node (GGSN) communicating with a packet inspection and service 
classification system (PISC) to which IP packets may be communicated for identi- 
fication of a given service class out of a number of predetermined service classes, 
the gateway node (GGSN) performing the steps of 

receiving an IP packet (11) from a packet data network (PDN, Gi), 

extracting the IP packet payload, 

receiving (31) a service class value for the payload, 

assigning the identified service class identity to a service class extension header 
(41), 

inserting the extension header (51) to a packet data packet unit (GTP-PDU) carry- 
ing the payload (21) and transmitting the packet data unit to a serving node (SGSN, 
Gn). 

15. A serving node (SGSN) communicating with a charging node (CAMEL-SCP), the 
serving node (SGSN) performing at least the following steps 

receiving a packet data unit (GTP-U) from a gateway node (GGSN, Gn) compris- 
ing a service class extension header (111), 

extracting a service class value (2'll) from the service class extension header, 

calculating and storing the volume count from the extension header for the re- 
ported service class for a given PDP context (3'll), 

transmitting the PDP payload towards a mobile station, 

reporting (411, 511) associated values of service class and volume count to a charg- 
ing node (CAMEL-SCP). 
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16. A serving node (SGSN) communicating with a charging node (CAMEL-SCP), the 
serving node (SGSN) performing at least the following steps 

receiving (1 II) a packet data unit (GTP-U) from a gateway node (GGSN, Gn) com- 
prising a service class extension header, 

extracting (2II) a service class value and volume count from the service class ex- 
tension header, 

storing (3II) the volume count from the extension header for the reported service 
class for a given PDP context, 

transmitting the PDP payload towards a mobile station, 

reporting (4II, 5II) associated values of service class and volume count to a charg- 
ing node (CAMEL-SCP). 

17. Serving node according to claim 15 or 16, wherein the storing (3'll, 31 1) of the vol- 
ume count involves accumulating a volume counter pertaining to a given PDP con- 
text. 

18. Serving node according to claim 15 or 16, wherein the charging node is a CAMEL 
node and the reporting hereto is following CAMEL reporting procedures. 

19. Serving node according to claim 15 or 16, wherein the accumulation of volume re- 
ports from classified and / or incompletely classified payload volume are main- 
tained as long as the PDP Context is active. 
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20. A gateway node (GGSN) communicating with a packet inspection and service 

classification system (PISC) to which payload of IP packets may be communicated 
for identification of a given service class out of a number of predetermined service 
classes, the gateway node (GGSN) performing the steps of 

continuously receiving (1111) downstream IP packets from a packet data network 
(PDN, Gi) interface for a given PDP context, 

continuously receiving (2111, 3111) service class identification for the IP packets, 

for those IP packets, which are incompletely classified (3111), transmitting the pay- 
load (5111) towards a serving node (SGSN), while storing (4111) the volume count 
and associated incomplete classification for a given PDP context, 

when being able to identify (8111) a service class for a payload belonging to a PDP 
context for which payloads were previously incompletely classified, assigning the 
identified service class (9111) and the aggregate volume count (10111) for the previ- 
ously incompletely classified payloads of the same PDP context to a service class 
extension header, 

inserting (1 1111) the extension header to a packet data packet unit (GTP-PDU) car- 
rying the payload and transmitting the packet data unit to a serving node (SGSN, 
Gn). 
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21 . A gateway node (GGSN) communicating with a packet inspection and service 

classification system (PISC) to which payload of IP packets may be communicated 
for identification of a given service class out of a number of predetermined service 
classes, the gateway node (GGSN) performing the steps of 

continuously receiving (11V) upstream packet data units to a serving node (SGSN, 
Gn) relating to a given PDP context, 

receiving (31V) the service class for the upstream payload, 

storing or accumulating (41V) uplink volume count per service class, 

when receiving (61V) a first downstream packet from a packet data network (PDN, 
Gi) relating to the same PDP context, 

receiving (81V) the service class for the downstream payload, 

preparing (101V) a service class header with the given service class for the up- 
stream payload and the saved or accumulated volume counts, 

preparing (121V) a service class header with the given service class for the down- 
stream payload and the corresponding volume count, 

inserting (1 1 1V, 131V) the extension headers to a packet data packet unit (GTP- 
PDU) carrying the payload (71V) and transmitting it to a serving node (SGSN, Gn). 
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0 0 


Comprehension of this extension header is not required. An 
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0 1 


Comprehension of this extension header is not required. An 
Intermediate Node shall discard the Extension Header Content and not 
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Endpoint Receiver or Intermediate Node) 
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2. 

The IP packet is identified as part of 
a PDP Context and the IP packet is stored 
in a GTP-U PDU. 



The IP packet payload is identified 
as belonging to a service class by PISC. 



A GTP-U extension header is prepared 
with the service class identity. 



5. 

The GTP-U extension header is included 

as part of the GTP-U PDU for which 
the service classification was performed. 



6. 

GGSN send the GTP-U PDU 
downstream towards SGSN. 



to fig. Ha 



Fig. lb 
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A downstream GTP-U PDU arrives 
at Gn interface of SGSN 




SGSN extracts the service class 
and volume count 
from the extension header 
of the GTP-U PDU. 



SGSN extracts the service class 
from the extension header 
of the GTP-U PDU. 



3. 

SGSN stores the volume count 
payload volume information 
as separate measurement 
information of that PDP Context. 



3'. 

SGSN calculates 
and stores the volume count 
payload volume information 
as separate measurement 
information of that PDP Context. 




4. 

Following normal CAMEL reporting procedures, 
SGSN reports CAMEL measurement. 
The CAMEL reporting is extended with volume report of 
the categorized payload. 



5. 

The SCP node applies differentiated charging from 
charging tariffs based on received categorization information. 



Fig. Mb 
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1. 

A downstream IP packet 
arrives at Gi interface. 



The IP packet is identified as 
part of a PDP Context and 
the IP packet is stored in 
a GTP-U PDU. 



3. 

The IP packet payload cannot by itse 
If beidentified to be of 
a specific service class. 
More IP packets are needed for 
a category identification. 



4. 

GGSN saves measurement 
information 
of the not categorized IP packet. 



5. 

GGSN sends the GTP-U PDU 
downstream towards SGSN. 



6. 

Another downstream IP packet 
arrives at the Gi interface. 



The IP packet is identified as part of 
same PDP Context as earlier incompletely 
classified IP packet and the received 
IP packet is stored in a GTP-U PDU. 



8. 

The IP packet payload is 
classified by PISC. 



9. 

Earlier received and not classified 
IP packet is identified to be of 
same service class as the new IP packet. 



10. 

A GTP-U extension header is prepared 
with the service class and 
volume count The volume count is 
the sum of the not yet reported volume 
count of the category for the PDP Context. 



5\ 

The sequence 1 to 5 may be 
repeated before continuing 



11. 

The GTP-U extension header is included 

as part of the GTP-U PDU for which 
the service classification was performed. 



to fig. I la 



Fig. Illb 



12. 

GGSN send the GTP-U PDU 
downstream towards SGSN. 
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1. 

An upstream GTP-U PDU 
arrives at the Gn interface 
of the GGSN. 



2. 

The IP packet is extracted 
from the GTP-U PDU. 



The IP packet payload is 

identified 
and classified hv PIS£L_ 



GGSN saves measurement 

information 
for the classified IP packet. 



5. 

GGSN sends the upstream 
IP packet 
towards the Gi interface. 



5'. 



The sequence 1 to 5 may be 
repeated before continuing 



to fig. I la 



Fig. IVb 



A downstream IP packet arrives 
at the Gi interface. 



7. 



IP packet is stored in a GTP-U PDU. 



8. 

The IP packet payload is identified 
and classified by PI SC. 



9. 

The IP packet is identified as part of 
the same PDP Context as 
earlier not reported 
IP packet payload measurement. 



10. 

GTP-U extension header is prepared 
with the service class 
information from saved 

measurement of upstream IP packets. 



11. 

The GTP-U extension header is included 
as part of the downstream GTP-U PDU. 



12. 

A GTP-U extension header is prepared 
with the service class identity. 



13. 

The GTP-U extension header is included 
as part of the downstream GTP-U PDU. 



14. 

GGSN sends the GTP-U PDU 
downstream towards SGSN. 



WO 2005/053224 



PCT/SE2003/001829 



14/14 



GGSN 
Gj interface 




Fig. IVa 



INTERNATIONAL SEARCH REPORT 



International application No. 

PCT/SE 2003/001829 



A. CLASSIFICATION OF SUBJECT MATTER 



IPC7: H04L 12/14, H04L 29/06 

According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC7: H04L 



Documentation searched other than minimum documentation to the extent that such documents are included in the fields searched 

SE,DK,FI,N0 classes as above 



Electronic data hase consulted during the international search (name of data base and, where practicable, search terms used) 



EPO-INTERNAL, WPI DATA, PAJ, INTERNET 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 1 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



US 2003120499 Al (MACLEAN, I ET AL), 26 June 2003 
(26.06.2003), figure 4, abstract, whole document 



WO 03047164 A2 (MARKPORT LTD), 5 June 2003 

(05.06.2003), page 6, line 23 - page 7, line 15; 
page 7, line 24 - page 8, line 10; page 9, line 15, 
page 10, line 8 - line 10; page 17, line 7 - line 
10, figure 1, claims 1-2, 4-5, 15-17, abstract 



1-21 



1-5 



US 2002127995 Al (FACCIN, S ET AL), 12 Sept 2002 
(12.09.2002), [0015]; [0017]; [0071]-[0072] ; 
[0091]-[0117], claims 1-2,4,21-24 and abstract 



6-13,14-21 



1-2,5 



"")({ Further documents are listed in the continuation of Box C. )( See patent family annex 



Special categories of cited documents: 

"A" document defining the general state of the art which is not considered 

tone of parti cular relevance 
"E" earlier application or patent but published on or after the international 
filing date 

L" document which may throw doubts on priority claim(s) or which is 
cited to establish the publication date of another citation or other 
special reason (as specified) 

"O" document referring to an oral disclosure, use, exhibition or other 
means 

*P" document published prior to the international filing date but later than 
the priority date claimed 



*T* later document published after the international filing date or priority 
date and not in conflict with the application but cited to understand 
the principle or theory underlying the invention 

"X" document of particular relevance: the claimed invention cannot be 
considered novel or cannot be considered to involve an inventive 
step when the document is taken alone 

"Y* document of particular relevance: the claimed invention cannot be 
considered to involve an inventive step when the document is 
combined with one or more other such documents, such combination 
being obvious to a person skilled in the art 

"&>" document member of the same patent family 



Date of the actual completion of the international search 

4 June 2004 



Date of mailing of the international search report 

2 1 -06- 2004 



Name and mailing address of the ISA/ 
Swedish Patent Office 
Box 5055, S-1 02 42 STOCKHOLM 
Facsimile No. +46 8 666 02 86 



Authorized officer 

Nabil Sebaa /LR 

Telephone No. + 46 8 782 25 00 



Form PCT/IS A/210 (second sheet) (January 2004) 



INTERNATIONAL SEARCH REPORT 



International application No. 

PCT/SE 2003/001829 



C (Continuation). DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 1 



Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



EP 1096743 Al (LUCENT TECHNOLOGIES INC), 2 May 

2001 (02.05.2001), column 7, line 28 - line 32; 
column 8, line 5 - line 15; column 9, 
line 5 - line 21, abstract 



3GPP TS 32.215 v 4.5.0: "Technical Specification 
Group Services and System Aspects; 
Telecommunication management; Charging management; 
Charging data description for the Packet Switched 
(PS) domain; (Release 4). September 2003 (2003-09), 
Retrieved from the internet: <URL: 
http : //www . 3gpp . org/f tp/Specs/html -i nf o/32215 . htm> 
Retrieved on 2004-06-04. See section 5.8 and 
section 7-7.2 



3GPP TS 29.060 v 6.2.0: "Technical Specification 
Group Services and System Aspects; 
General Packet Radio Service GPRS); GPRS Tunneling 
Protocol (GTP) across the Gn and GP interface 
(Release 6), September 2003 (2003-09), 
Retrieved from the Internet: <URL: 
http : //www . 3gpp . org/f tp/Specs/html -i nf o/29060 . htm> 
Retrieved on 2004-06-04. See section 7.7.26, page 
22, paragraphs 1-2; sections 6; 7.3.8 - 7.3.9 



1-21 



1-21 



6-13 



Form PCT/ISA/210 (continuation of second sheet) (January 2004) 



INTERNATIONAL SEARCH REPORT 

Information on patent family members _ _ . 



30/04/2004 



International application No. 

PCT/SE 2003/001829 



119 

UJ 


900^120499 


Al 


Pfi/Ofi/2003 


NONE 






wo 


03047164 


A2 


05/06/2003 


NONE 






us 


2002127995 


Al 


12/09/2002 


CN 


1444824 T 


24/09/2003 










EP 


1310085 A 


14/05/2003 










JP 


2004507127 T 


04/03/2004 










WO 


0191446 A 


29/11/2001 










US 


6584737 B 


01/07/2003 










US 


2003121220 A 


03/07/2003 


EP 


1096743 


Al 


02/05/2001 


NONE 







Form PCT /ISA/210 (patent family annex) (January 2004) 



